- 14 feb.

Nyhetsbrev OT-Säkerhet #59

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! En massa cool teknik blir det den här gången - inte mindre än två tester av riktigt trevlig teknik, direkt från hemmalabbet! Jag filosoferar kring hur man kan spara en massa administrativ tid genom klok segmentering. Det blir mycket snack om EU-lagar också, det är verkligen ett hett område just nu!

Om det är första gången du läser ett av mina nyhetsbrev kanske du undrar vad det där "OT" är som jag pratar om? OT står för Operational Technology vilket är ett syskon till IT, Information Technology. Läs mer om det här i det här nyhetsbrevet!

Jag vill ge er ett stort tack för alla trevliga mejl jag får med frågor, förslag och uppmuntrande ord. Det här nyhetsbrevet är ju något som jag fortfarande tycker är väldigt roligt att skapa, vilket förstås är viktigt eftersom det till största delen skrivs hemma i TV-soffan. Som vanligt vill jag gärna att du delar med dig av nyhetsbrevet till kollegor som kan vara intresserade! Ju fler som läser, desto bättre möjligheter får jag att producera bra innehåll framöver! Om du vill ha nyhetsbrevet i inkorgen i fortsättningen är det bara att anmäla dig på www.ot-säkerhet.se eller dra ett mejl till mig på mats@ot-sakerhet.se. Jag lovar att din mejladress inte används till något annat än detta!

Du hittar alla tidigare utgåvor av nyhetsbrevet på www.ot-säkerhet.se. När det kommer nytt material så annonserar jag det på en massa ställen: min Linkedin-profil, i dess egen LinkedIn grupp, i Facebook-gruppen Säkerhetsbubblan, på Mastodon, på Twitter och på en egen Facebook-sida. Du kan också prenumerera via RSS på www.ot-säkerhet.se.

Ge mig gärna mothugg, frågor eller förslag på LinkedIn där den här utgåvan delades. Tänk på att du kan hjälpa mig, mer än du kanske tror, genom att trycka "like" på artikeln och genom att dela den vidare. Tack för hjälpen!

Nya tider!

Min högst personliga åsikt är att någonting hände vid nyår. Helt plötsligt pratar alla organisationer om NIS2. Är det så enkelt att det är ny budget och nya mätetal eller har poletten trillat ner ute i landet? I vilket fall som helst har tillströmningen av nya spännande kunder som vill ha stöd i gränslandet där NIS2 möter OT-säkerhet verkligen exploderat. Jag stöter på alla tänkbara varianter på hur man ser på lagstiftningen och på hur den egna organisationen "drabbas". Allt från den väldigt sunda inställningen "Vi omfattas inte av NIS2 men våra kunder gör det - låt oss kapa åt oss konkurrensfördelar genom att bli duktiga på säkerhet" till struts-taktiken "Nä, det verkar lite konstigt att vi skulle vara samhällsviktiga så det måste vara fel!".

Om man inte är så intresserad av EU, lagstiftning eller kravstandarder kan tyckas vara väldigt mycket snack om lagstiftning nu, inte minst i det här nyhetsbrevet! Men jag tror faktiskt kombinationen av NIS2, CRA och Maskinförordningen kommer ha en enorm effekt på hur vi arbetar med risk och säkerhet kring våra OT-system. Och ALLA kommer påverkas även om man inte själv faller direkt under någon av lagstiftningarna. Som vanligt kommer vi förmodligen överskatta effekten på kort sikt, men samtidigt underskatta den på lite längre sikt.

Apropå längre sikt så meddelade justitieministern i Nederländerna nyligen att man inte kommer hinna klart med NIS2 och CER till deadline den 17:e oktober. Några dagar senare annonserade det danska försvarsministeriet liknande problem. Andra länder, med Finland i spetsen, ligger väldigt bra till. Vi får se hur det går i Sverige, utredningen har sin deadline i slutet av februari och då kanske planen framåt klarnar lite? Det är många steg kvar tills allt är klart...

Samtidigt förändras sättet man bygger system på ett ganska radikalt sätt. Även här kommer det ta lite längre tid än vad vi tror (eller hoppas) men det kommer! Se exempelvis texten längre ner om den möjliga trenden att lämna OPC UA till fördel för MQTT, en detalj kan tyckas - men ändå. Ett annat exempel är det där läskiga begreppet "IT/OT-convergence" som många tror bara handlar om teknik, när det stora skiftet snarare (om du frågar mig) kommer handla om människor och arbetssätt. Sakta men säkert ser vi människor som är vana vid arbetssätten inom IT börja närma sig OT-världen och i takt med det kommer nya produkter - exempelvis är det äntligen dags för virtuella PLC:er, helt nya utvecklingsverktyg (läs exempelvis den här texten av Peter Kurhajec om Siemens SIMATIC AX) och nya sätt att bygga mjukvarudefinierade nätverk (exempelvis Veracitys nya nätverksappliance).

Det här gör att vi i OT-säkerhetsbranschen verkligen behöver hänga med i utvecklingen för att inte uppfattas som de gamla vanliga stoppklossarna som säkerhetsfolk lätt blir. Jag skrev om detta för några utgåvor sedan, när jag jämförde säkerhetsarbete med teatersport. Det gäller verkligen att arbeta in de nya lagkraven och de nya arbetssätten i detta. Om säkra system ska möjliggöra nya verksamheter och affärer behöver vi sluta svara "Nej, det är för osäkert" eller "Nej, det får man inte enligt NIS2" och istället säga "Ja, om vi löser X och Y för att möta CRAs krav" eller "Ja, men då behöver vi byta till en modern arkitektur".

Det är spännande tider som väntar oss framöver! ...och apropå tid...

Ur led är tiden!

Den klassiska frasen fick vi av Shakespeare i Hamlet, men det var nog inte våra datorers klocksynkronisering han tänkte på. I takt med att tiden spelar en allt viktigare roll för många delar i våra OT-system blir det också viktigare att hålla koll på klockorna i alla system. De behöver gå rätt och de behöver gå lika.

Det är inte helt ovanligt att man använder någon form av GPS-baserad mottagare för att få en bra referensklocka att utgå ifrån och sedan sprider tiden i nätverket med exempelvis NTP-protokollet. På senare tid har det blivit väldigt uppenbart att GPS-systemet är sårbart för attacker, både för navigerande flygplan och för dem som vill ha rätt tid! På samma sätt kan man tänka sig att välkända tidskällor på Internet skulle utsättas för attacker.

Keysight är ett företag vars produkter jag testat och skrivit om förut, det har exempelvis varit nätverkstappar eller aggregationsswitchar för att samla in kopior av all nätverkstrafik. I nyhetsbrev 29 skrev jag om deras brutala nätverkstestare BreakingPoint. Det totala produktsortimentet innehåller en närmast bisarr mängd coola lösningar. Den här gången har jag tittat på en produkt som heter Timekeeper.

Timekeeper gör precis vad namnet hintar om, den håller koll på tiden från ett antal valfria källor. Kvaliteten på tids-informationen analyseras hela tiden (!) och kan presenteras i grafer och statistik. Om någon tidskälla avviker på ett orimligt sätt eller om någon signal visar tecken på att vara spoofad så kommer den att ignoreras när "rätt tid" bestäms.

"Den rätta tiden" kan sedan spridas på nätverket via NTP. I exemplet nedan ser du en graf över hur det såg ut i mitt hemmalabb. Timekeeper är vid pilen, och ovanför finns de NTP-källor som är konfigurerade och nedanför är några av de klienter som hunnit ansluta.

NTP i tillsammans med Timekeeper är en imponerande kombination. Timekeeper är löjligt enkel att få igång och avvikelserna i tiden ligger på några tusendelar av en sekund bara genom att använda öppna NTP-källor på Internet. Om man vill ansluta egna GPS-mottagare eller PTP-källor så finns stöd för det också. Underskatta inte behovet av bra tid, det uppstår väldigt märkliga fel när tiden är dåligt synkad...

Jag avslutar med en tråkigare nyhet, nämligen att Dave Mills som uppfann NTP nyligen gick ur tiden (!) vid 85 års ålder. Jag skickar en tacksam tanke till honom och alla andra pionjärer som lade grunden till mycket av det vi tycker är självklart, men fortfarande spännande, idag.

Mindre slit genom att göra mer?

OT-Säkerhet är ett område som ger oss många spännande utmaningar. Men ibland känns det frustrerande att de säkerhetsåtgärder vi tar inte ”räcker hela vägen”. En anledning till det tror jag kan vara att man försöker implementera en åtgärd åt gången istället för att se hur olika åtgärder kan förstärka varandra. Ett intressant exempel på två områden som verkligen kan förstärka varandra är sårbarhetshantering och segmentering.

Med sårbarhetshantering menar jag i det här sammanhanget det håra arbete som man står inför om man ska försöka hänga med i alla nya sårbarheter som annonseras för att kunna analysera hur de slår mot alla komponenter man har och i vilka sammanhang som det faktiskt är värt att störa produktionen för att lägga på en säkerhetsrättning. Det är ju här som skillnaderna mot IT-världen kanske blir som allra tydligast för många.

När jag pratar om segmentering tänker jag främst på arbetet att dela upp nätverk, dataflöden och system inom OT-miljön. Att separera ”IT” och ”OT” förutsätter jag är hanterat även om mitt resonemang här skulle kunna fungera lika bra på den uppdelningen.

För båda dessa utmaningar blir en absolut förutsättning för att kunna göra någonting alls att man har tillgång till pålitlig information om vilka komponenter man har, hur de sitter ihop och hur dataflöden mellan dem ser ut. Det betyder (som vanligt) att vi är beroende av att vi har verktyg och processer som hjälper oss med detta.

Att löpande bedöma vilken risk som nya sårbarheter orsakar för organisationen är ett tufft jobb av många skäl. Ett sådant skäl är att även en enkel systemmiljö har många komponenter som var för sig kan påverka helheten på kluriga sätt. Det är här som kopplingen till segmenteringsarbetet blir en möjlighet att göra arbetet mycket enklare.

Arbetsordningen för att bedöma en ny sårbarhet kan se ut så här:

Bevaka alla relevanta källor för att fånga upp alla nya sårbarheter som eventuellt kan vara aktuella någonstans
För varje sårbarhet:
1. Förstå sårbarheten (Vad påverkas, hur och under vilka förutsättningar?)
2. Identifiera alla komponenter i vår miljö som möjligen berörs av sårbarheten
3. För sårbarheten - bedöm varje komponent:
  1. Går sårbarheten att utnyttja i just denna komponenten på det sätt den används hos oss? (Med tanke på andra skydd och arkitekturen)
  2. Hur påverkas komponentens pålitlighet om sårbarheten utnyttjas?
  3. Hur påverkar verksamhetens risk av att komponenten inte går att lita på?
  4. Vilka skydd finns som kan minska verksamhetens risk? (Härdning, segmentering etc?)

Ett av problemen med det här resonemanget är att alla komponenter både blir en potentiell sårbarhet OCH samtidigt en del av skyddet mot angrepp. Det gör att analysen blir väldigt komplex! Jag föreslår att vi istället vänder resonemanget på huvudet och utgår ifrån att alla komponenter alltid kommer vara sårbara och istället fokuserar på att omgärda dem med tydliga säkerhetsåtgärder. Då behöver vi bara bedöma hur säkerhetsåtgärderna eventuellt påverkas av den nya sårbarheten medan vi vi med flit struntar i allt som inte är exponerat. Det låter ju onekligen lite enklare… Om du tycker det här låter som en jobbig kompromiss så har du förmodligen rätt. Att jag tycker den i många fall är okej är att man i slutänden ändå väljer att skjuta upp patchningen på grund av något annat skydd, exempelvis just segmenteringen.

Med det tänket blir bra säkerhetsåtgärder extremt avgörande och det är här kopplingen till segmenteringsarbetet dyker upp. Jag tänker mig att vi gör en ”riktig” segmentering i still med vad IEC 62443 del 3 pekar på, och använder säkerhetszoner (”Zones” i standarden) som sammanbinds av det standarden kallar ”Conduits”. När folk pratar om segmentering brukar det lätt bli en ren nätverksfråga och det är här nästa nyckel till mitt resonemang finns. Tricket ligger i att vara så pass systematisk i designen att man faktiskt har koll på vad som exponeras i respektive system. Att göra det ur ett nätverksperspektiv är inte så svårt, det handlar ofta om att öppna portar i något slags brandvägg. Utmaningen ligger i att hantera det som exponeras!

Ett exempel på varför det här är viktigt: Det vanligt att jag stöter på organisationer där man noggrant segmenterat sitt nätverk men att man samtidigt tillåter Windowsdatorer att prata ganska fritt över segmenteringsgränserna för att komma åt filer, använda Active Directory, skriva ut osv… Det innebär att man segmenterat nätverket på ett sätt, men ur ett Windowsperspektiv så ser segmenteringen väldigt annorlunda ut! Det betyder att en Windows-tjänst som exponeras i en säkerhetszon potentiellt ”drar med sig andra säkerhetszoner i fallet”. Det går ofta inte att undvika men då ska vi ha koll på det och bygga vårt riskresonemang utifrån det! Exempelvis undvika att hamn i situationer där en Windows-dator med flera nätverksanslutningar används för att knyta ihop olika nätverk eller säkerhetszoner, då har en redan onödigt stor säkerhetszon blivit ännu större och väldigt mycket mer komplex.

Om vi gjort en klok segmentering och därmed har koll på vilka säkerhetsåtgärder vi har och vilka tjänster i andra komponenter som är exponerade behöver ovanstående metod för att analysera en sårbarhet bara titta på säkerhetsåtgärderna och de exponerade tjänsterna. Det är en enorm minskning av mängden arbete, både för att volymen är mindre men också för att den ordning och reda man skapat gör det väldigt enkelt att identifiera vad som är relevant att bedöma! Om man kan dra nytta av moderna sätt att annonsera sårbarheter går det dessutom att automatisera en del av arbetet!

Eftersom uppdelningen i ”Zones” och ”Conduits” är tänkt att vara riskstyrd blir nästa nytta man kan ta del av att bedömningen av en sårbarhet blir enklare eftersom det är möjligt att definiera en enhetlig riskprofil per Zone och Conduit.

Observera att grunden för att kunna dra nytta av detta inte i första hand är tekniska lösningar, utan en klok metod för att göra och dokumentera hur man designat segmenteringen, tillsammans med vettiga procedurer för hur man följer med i floden av annonserade sårbarheter.

Däremot är tekniken förstås helt avgörande för att kunna implementera detta i praktiken. Nätverkssegmentering kan exempelvis vara en valfri kombination av klassiska centrala brandväggar med tillhörande switchar (exempelvis Fortinets prylar), lokalt skydd ute i anläggningen (exempelvis TxOnes Edge-serie) eller mjukvarudefinierade nätverk (exempelvis Veracity). När det gäller komponentinventering, trafikflödesanalys och riskanalys kan det vara bra med en valfri kombination av specialiserade verktyg för inventering (exempelvis OTbase), en modern detekteringsplattform (exempelvis Nozomi) eller en plattform för förebyggande riskanalys (exempelvis Otorio RAM2). Som vanligt blir bra verktyg helt fantastiska i händerna på något som använder dem rätt!

Vad är kemikalier egentligen?

Arbetet med att få NIS2 att landa i alla EUs länder pågår, vissa länder gör som Sverige och implementerar en nationell lag, medan andra länder har andra metoder. När den delen är klar återstår ett väldigt intressant arbete, nämligen att reda ut vad kraven i direktivet egentligen betyder i vardagen. Det finns nämligen en del klurigheter i direktivs-texten som går att tolka lite olika.

Jag har själv hängt upp mig lite på en av dem, frågan om vad som egentligen ingår i kemikalie-sektorn? (Extremt nördigt - jag vet! Sorry...) Vilka organisationer som omfattas av direktivet är ju onekligen en viktig fråga och här är det faktiskt inte speciellt tydligt i mina ögon. Eller egentligen... Det är jättetydligt men på ett sätt som inte känns rimligt!

Bland alla nya sektorer som ingår i NIS2 finns punkten "Tillverkning, produktion och distribution av kemikalier" med i listan. Det låter ju ganska uppenbart vad det handlar om ifall man använder den vardagliga definitionen av vad en kemikalie är. Utmaningen är den sista delen av definitionen som du ser i bilden här ovan: "...företag som producerar varor ... genom att använda ämnen och blandningar".

Klurigheten uppstår när man tar reda på vad EUs definition av orden "varor", "ämnen" och "blandningar" är. Enkelt uttryckt är en vara något vars funktion framför allt bestäms av vilken fysisk form den har, medan ett ämne och en blandning helt enkelt är ett eller flera grundämnen utan någon speciell funktion. Vill du dyka i de exakta definitionerna så hittar du dem i EUs kemikalieregelverk "REACH" under "Artikel 3":

Då är frågan, vad har vi för vardagliga exempel på verksamheter som tar ett eller flera ämnen och producerar en vara av dem? Det måste ju vara viktigt eftersom det innebär att man då automatiskt definieras som samhällsviktig verksamhet! Det finns nämligen inga andra generella begränsningar eller undantag i direktivet; är du verksam i en sektor som omfattas av direktivet och har en tillräckligt stor verksamhet så träffas du av NIS2!

Vad tror du om exemplen nedan? Visst är de alla rimliga exempel på att man tar ämnen och gör varor av dem? Känns någon av dem som rimliga exempel på verksamheter som automatiskt bör vara samhällsviktiga?

Tillverka synålar av stål
Valsa ut ugnsfolie av aluminium
Göra elektriska ledare av koppar
Göra örhängen av silver

Naturligtvis kan de här typerna av verksamheter att vara väldigt viktiga för vårt samhälle! Men är alla det? Den mest extrema slutsatsen blir ju faktiskt att alla producerande verksamheter som använder kemikalier i produktionen kommer omfattas av direktivet eftersom det knappast går att skapa något annat av kemikalier förutom varor eller andra kemikalier!

Allt det här känns intuitivt inte rätt! Jag har svårt att tro att det här var tanken med den här definitionen. Men var drar man gränsen då? Och baserat på vilken regel? Jag har skickat den här frågan till lämpliga instanser inom EU, kontaktpersoner på myndigheter i både Sverige och andra länder, till jurister jag känner samt en rad andra kloka kontakter men hittills inte fått något tydligt svar på var jag resonerar fel.

Det finns fler gränsdragningar som behöver bli tydligare kring hur NIS2 ska begränsas. Är dessa rimliga exempel?

Ett stort företag med en verksamhet som inte alls träffas av NIS2 skaffar en massa solceller på taket till fabriken och blir därmed elproducent - Omfattas!
En större industri utan koppling till NIS2 säljer spillvärme till det lokala fjärrvämenätet - Omfattas!
En stor bilverkstad som sätter upp laddstolpar för allmänhetens elbilar - Omfattas!

De enda områden som jag känner till där det krävs en viss omfattning av verksamheten är dricksvattenproduktion, avloppsrening, avfallshantering och möjligen livsmedelsproduktion. I övrigt kan det vara en väldigt liten del av din totala verksamhet men ändå göra dig till en NIS2-verksamhet.

Här vore jag väldigt tacksam om du som läsare kan hjälpa till att bringa klarhet! Hör av dig med inspel eller tankar till mats@ot-sakerhet.se ! Speciellt om du faktiskt jobbar i någon av alla de verksamheter som skulle träffas av den här tolkningen - hur har ni tänkt i er NIS2-analys?

Säker fjärranslutning är enkelt!

Ett område som ALLA verkar ha utmaningar med är fjärranslutning till OT-system. Det är en väldigt viktig funktion för att hålla igång produktionen, men också en av de mest utsatta delarna ur ett säkerhetsperspektiv! När jag träffar nya kunder brukar det alltid dyka upp alla möjliga spännande lösningar, med mer eller mindre genomtänkt säkerhet. Det här är ett kul område eftersom det är ganska vanligt att man kan skapa verklig nytta genom förbättrad säkerhet! Underhållspersonal, utvecklare, integratörer eller leverantörer kan skapa mycket mer värde om de snabbt kan få åtkomst, oavsett om det är från andra sidan jordklotet eller från kontoret i andra änden av industriområdet!

Oavsett i vilken bransch man är brukar ungefär samma saker dyka upp när verksamheter sammanställer sina krav på säker fjärråtkomst till OT, det kan vara:

Användbar för både egna anställda och för leverantörer.
Ingen installation av programvaror hos den som ska koppla upp sig. (Speciellt viktigt för leverantörer som inte rimligen kan ha mängder med olika klienter och agenter på sina datorer.)
Smidig att använda både externt över Internet och mer internt från IT-nätet.
Smidig hantering av användare, gärna kopplad till någon separat identitetstjänst.
Flerfaktorinloggning för säkrare identifiering och minska risken för delade inloggningar.
Behörighetshantering och roller för att styra vem som får komma åt vad.

Så här långt finns det ganska många produkter som möter kraven, det är egentligen ganska likt kraven för en typisk IT-miljö. Men när man börjar ställa lite "vassare" krav ur ett OT-perspektiv börjar det bli klurigare:

Vid oväntade behov av fjärrstöd ska man väldigt snabbt kunna skapa åtkomst till en ny person utan att blanda in "IT-avdelningen".
Inspelning av sessioner för att i efterhand kunna avgöra vad som hände.
"Eskorterad inloggning", alltså att man släpper in någon på distans, men "tittar över axeln på dem" medan de är uppkopplade och kan avbryta arbetet om något är på väg att gå snett.
Att kunna släppa in en besökare i ett system utan att man behöver dela inloggningsinformation till systemet. (Något slags lösenordsvalv och stöd för semi-automatisk inloggning.)
Undvika att skapa en direkt tunnel mellan klientdatorn och systemet man kopplar sig mot. (Om man kan bryta den direkta nätverkskopplingen som man får via en vanlig VPN så är många risker eliminerade. En vanlig källa till problem är att leverantörernas datorer över tid är anslutna till väldigt många olika system, och därför tenderar att "samla på sig" diverse skadlig kod och annat tråkigt.)
Stöd för hierarkiskt uppbyggda organisationer där olika bolag i samma koncern ska kunna samarbeta men samtidigt ha egen kontroll över sin egen miljö.
Kunna skapa åtkomst till finmaskigt segmenterade och komplexa nätverk utan att man "kortsluter" segmenteringen.
Stöd för end-to-end-kryptering och samtidigt något som liknar zero-trust på riktigt.
Smidiga metoder för godkännande av inloggningar.
Stöd att bygga en robust arkitektur helt utan "Single-points-of-failure".
Kunna fungera även i miljöer som kräver fullständig isolering från Internet eller som vill ha egen kontroll över alla komponenter.
Baserad på modern teknik, lättanvänd utan utbildning, snabb att implementer och inte resurskrävande för vare sig människor, nätverk eller system.
Full loggning av händelser och spårbarhet för ändringar i systemet för fjärruppkoppling.
Undvika jumphosts och liknande lösningar som ofta blir en svag punkt underhållsmässigt och dessutom en potentiell kortslutning i ett segmenterat nätverk.

På plats i mitt kära hemmalabb finns numera en lösning som imponerat stort på mig och som jag personligen tycker bockar av alla krav som vanligen ställs på fjärråtkomst till OT! Jag tänkte ge dig en översikt här, men får nog anledning att återkomma kring några speciellt intressanta detaljer i framtida nyhetsbrev.

Både produkten och företaget heter Cyolo. Lösningen bygger på två mjukvaru-komponenter, "Edge" och "IDAC" (ID Access Control), som man kombinerar ett valfritt antal av för att bygga upp en robust och snabb lösning. Det är i IDAC som allt intressant händer, medan Edge enbart har som funktion att knyta samman kommunikationen. En väldigt intressant styrka är att ingen känslig kommunikation någonsin dekrypteras i en Edge. All kommunikation sker krypterat hela vägen mellan klientsystemet och en IDAC, även om den passerar en eller flera Edge på vägen! Det betyder också att all känslig information bara lagras i system som är under organisationens egen kontroll, ingenting finns hos leverantören.

Cyolo erbjuder som du ser på bilden nedan en molnbaserad, generell Edge-tjänst som fungerar ihop med alla installationer som vill använda den, eller så sätter du upp en eller flera egna Edge-tjänster som du exponerar på Internet. En finess med att "studsa via" molntjänsten är att dina egna Edge-tjänster inte behöver vara åtkomliga ute på Internet.

Oberoende av hur du har segmenterat dina OT-nätverk finns det många olika sätt att flexibelt skapa styrd åtkomst dit det behövs. Edge-funktionen löser att kommunikationen kommer fram och IDAC ser till att du kan skapa anslutningar på rätt ställen. Och vill du inte ha Cyolo exponerad alls mot Internet så funkar det lika bra med 100% on-prem.

Under huven finns ett modernt tänk där de valt att använda Docker-containers för att skapa stabil drift samtidigt som uppdateringar kan ske så gott som utan påverkan på driften. För att maxa tillgängligheten är det också väldigt enkelt att skapa klustrade lösningar över flera sajter. Det gör att störningar i samband med driftproblem eller uppdateringar hanteras automatiskt och snabbt. Det innebär också att det är superenkelt att börja litet för att sedan lägga till efter hand som man behöver mer åtkomst och stabilare drift.

Installationen i testlabbet gick oerhört smidigt: Jag skapade en Ubuntu-server, körde ett installationsskript och kopierade in en licensnyckel. Sedan är det igång - inklusive full, och säker, administration från Internet om så önskas! Första gången du loggar in som administratör tvingas du sätta din flerfaktor-identifiering, exempelvis Google Authenticator eller något liknande.

Vi kan börja med att titta på några sätt som det här kan fungera ur användarens perspektiv. Den första är nästan lite magisk; du sätter nämligen i princip vilken intern applikation som helst ute på Internet, men bakom flerfaktorinloggning, över krypterad länk och med möjlighet till en rad andra säkerhetsåtgärder!

En leverantör som bara ska arbeta på distans i ett webb-baserat internt system får en extern länk direkt till det systemet! I mitt fall sköter jag exempelvis min Proxmox-administration genom att surfa till en länk i stil med https://proxmox.otsäkerhet.cyolo.io! Jag får en Cyoloinloggning med flerfaktorautentisering och sedan landar jag direkt i administrations-webbsidan hemma hos mig! Där får jag logga in som vanligt och kan arbeta precis som om jag satt hemma!
På samma sätt som ovanstående exempel kan användaren komma in via protokoll såsom SSH, VNC, Telnet, RDP osv. Användaren jobbar direkt i webbläsaren men den sista delen av kommunikationen, den mellan IDAC och systemet, sker förstås med "rätt" protokoll. Alternativt sätter man upp exempelvis RDP-åtkomst i "bägge ändar" av förbindelsen, vilket förstås kräver tillgång till lämplig klientprogramvara men förbindelsen skapas och skyddas automatiskt av Cyolo.
En variant på ovanstående är om jag släppa in någon som jag inte vill ska veta om inloggningen i själva systemet. Då kan jag lagra inloggningen (exempelvis för Proxmox i mitt fall) i lösenordsvalvet som finns inbyggt i IDAC:en och låta inloggningen ske automatiskt när personen ansluter med sitt eget lösenord. Perfekt funktion även internt, för system där många tvingas dela på samma lösenord - ingen behöver kunna det verkliga lösenordet och bara de som ska ha personlig åtkomst får det och med full spårbarhet...
Ett vanligt case är att någon ska köra TIA Portal, PLCnext Engineer eller något annat specifikt verktyg på distans. En elegant lösning på det är att Cyolo efter inloggning fixar en lokal port på remote datorn, som magiskt transporteras till exakt den port som behövs för applikationens funktion. Bara en port och bara mellan dessa två system! Och detta utan att installera några agenter på systemet...

Du kan erbjuda åtkomst till en Windows-fildelning (SMB) som man kommer åt i ett webb-gränssnitt istället för att oroa sig över att exponera sårbarheter i Windows.
Om man absolut vill använda Cyolo som en "en gammaldags VPN" med full åtkomst till ett nätverk så går det också. Det är inte säkerhetsmässigt optimalt, men är ibland nödvändigt.

Ur en säkerhetspersons synvinkel är möjligheterna att erbjuda applikationer ett fantastiskt sätt att skapa verksamhetsnytta. Ur ett rent säkerhetsperspektiv kompletterar man det med att styra åtkomst och sätta policies kring användningen. Några intressanta exempel på vad man kan styra åtkomst till en viss applikation baserat på:

Användarens identitet eller de grupper man tillhör
Om inloggning skett med flerfaktorinloggning
Vissa tider och dagar
Anslutning från nätverk i utvalda länder
Anslutning från vissa IP-adresser eller nät
Anslutning från vissa klientsystem som får identifiera sig med certifikat
Egenskaper hos enheten man kopplar upp sig från, exempelvis viss version av operativsystemet, ett installerat virusskydd, lokal brandvägg, krypterad hårddisk eller domäntillhörighet
Krav på "eskorterat besök" baserat på användarens identitet eller applikationen man ska använda. I korthet handlar det om att en person eller en grupp personer aktivt ska godkänna att uppkopplingen sker. Man kan sedan även övervaka vad som händer under uppkopplingen.
Krav på att sessionen ska spelas in
Integrationer med andra applikationer kan användas för att kontrollera lämpligheten i att koppla upp sig, genom ett API eller WebHooks. Exempelvis skulle en EDR-lösning (Endpoint Detection & Response) kunna bekräfta att ingen skadlig kod finns på systemet eller ett SCADA-system kan bekräfta att processen är i säkert läge.

Dessutom kan man välja vilken funktionalitet som ska vara tillgänglig för användaren under en uppkoppling. Lite beroende på vilken typ av anslutning som är aktuell så kan det handla om att tillåta Cut&Paste, inspelning av sessionen, port forwarding, interaktivt samarbete med den som eskorterar, uppladdning av filer, nedladdning av filer och en massa annat.

Hanteringen av identiteter är förstås väldigt central för alla sådana här lösningar. Plattformen kommer med egna IdP:er (Identity Providers) men beroende på dina krav så kanske du vill integrera med existerade identitetskällor (exempelvis Okta, Azure AD, JumpCloud, AD eller Duo) via något av de typiska protokollen som används för detta (SAML, OpenID, RADIUS eller LDAP). Det finns enkla beskrivningar för alla kombinationer av lösningar och stöd för exempelvis SCIM ("System for Cross-domain Identity Management") så att man automatiskt kan bygga upp användarlistan. Men det finns goda anledningar att använda Cyolos egen användardatabas också, exempelvis:

Du vill ha en lösning som är fullständigt oberoende av yttre tjänster
Du vill separera identitetshantering från flerfaktorsinloggning så de blir oberoende (exempelvis inte köra Azure AD tillsammans Microsofts MFA)
Du vill spara på licenskostnader
Du vill hantera användare från dina leverantörer separat från den interna hanteringen

Det finns ett "lösenordsvalv" inbyggt i lösningen. Det möjliggör att den som ansluter till ett system inte behöver kunna lösenordet som används för att ansluta. Det är en fantastisk finess för att få spårbar och personlig anslutning till utrustning som bara har ett enda lösenord! Det är inte bara lösenord som kan lagras i valvet utan även andra typer av hemligheter, som privata kryptonycklar, certifikat och API-nycklar. Förutom ett systemvalv finns även ett personligt valv för varje användare som möjliggör att man kan spara lösenord som kan möjliggöra automatisk inloggning.

Cyolo är väldigt väl anpassad för OT-användning men det passar minst lika bra för olika typer av IT-scenarier. Det finns stöd för SaaS-applikationer och en massa möjligheter att integrera med olika identitetstjänster och SSO-lösningar. När det blir lite mer komplext kan man koppla upp applikationsspecifika tunnlar mot flera olika system samtidigt.

Allt som händer i systemet loggas noggrant, både användares aktiviteter och ändringar som administratörer gör. Loggningen, tillsammans med möjligheten till inspelning av sessioner, gör att man kan skapa extremt snygg spårbarhet. En viktig del för att analysera problem och incidenter!

Man bör förstås också se till att anslutningar som kommer in på distans passerar förbi andra säkerhetssystem man redan har på plats. Det vore ju fånigt om IDS:er och annat inte fick "hjälpa till" att kontrollera även dessa anslutningar! Vilket förstås kräver klok placering av IDAC.

Sammantaget är Cyolo en vansinnigt imponerande lösning. Den har mycket starka funktioner och kan enkelt skapa robust tillgänglighet, men ändå relativt enkel konfiguration och administration! Det blir verkligen en stor vinst säkerhetsmässigt att inte slentrianmässigt släppa in folk i känsliga nätverk via "vanlig VPN" utan istället använda en OT-anpassad lösning för att bryta upp de direkta nätverksförbindelser som annars blir möjliga. Om man inte vill göra sig beroende av externa tjänster går det utmärkt att skapa en helt lokal lösning som fortsätter att fungera även om tvingas isolera en anläggning under en incident. Stark rekommendation!

Underhåll och ändringar...

Apropå remote access och segmentering så hittade jag nedanstående siffror i en årsrapport från TxOne. Nu tar jag alltid sådana här siffror med en rejäl nya salt men oavsett källan och vad man menar med "OT-säkerhetsincident" så väcker det tankar... Det är onekligen något som jag känner igen mig i, det är inte (än så längre) hackers som är orsaken till de flesta säkerhetsincidenter i produktionsmiljöer. Det är istället våra egna arbeten i miljön, antingen direkt via underhållsarbete eller indirekt när IT-system råkar störa något i produktionen. Förutom vettiga arbetsrutiner och "ordning och reda" så blir förstås styrd åtkomst till system och separation från andra system en viktig del i att undvika problem.

Språket spelar roll!

Jag har i diverse sammanhang påpekat att man får se upp med vilket språk man läser standarder och lagkrav på. Man kan ju exempelvis tycka att det är fantastiskt att EUs alla viktiga dokument översätts till 24 olika språk, men det finns ju samtidigt en risk att det uppstår otydligheter när dessa översättningar skapas. Mina juristvänner berättar för mig att det är den engelska och franska versionen som väger tyngst om det blir tolkningsfrågor inom EU.

Jag har hittat en del ställen där exempelvis NIS2-direktivet inte riktigt sänder samma signaler på olika språk. Häromdagen läste jag i en artikel att NIS2 kräver att man använder "state-of-the-art" i sina åtgärder vilket fick mig att börja jämföra olika språk.

Här är den engelska versionen som mycket riktigt säger att man ska väga in moderna möjligheter när man utformar sitt skydd:

Om man läser motsvarande text på svenska, så får i alla fall inte jag samma budskap. "State-of-the-art" och "de senaste" sänder inte riktigt samma signaler...

Det finns fler klurigheter i översättningarna, en personlig favorit är kring gränsdragningen mellan Väsentlig och Viktig när det kommer till organisationens storlek. På engelska talar man om att Väsentliga ("Essential") måste överstiga taket ("Ceiling") för vad som är en medelstor organisation.

Motsvarande text på svenska talar om "trösklar", vilket i alla fall jag tolkar som en nedre gräns för någonting, i motsats till "tak" som känns som en övre gräns:

Man kan alltså lätt tro att ett "Medelstort företag" automatiskt blir Väsentligt om man läser den svenska texten, men den korrekta tolkningen är att det krävs nästa storleksordning. I det här fallet skulle konsekvenserna bli att man drar på sig radikalt högre krav om man av misstag ser sin organisation som "Väsentlig"!

Nu är det ju inte meningen att alla ska sitta och läsa lagtext, men eftersom tiden är kort tills implementationen av alla NIS2-åtgärder ska vara klar så blir man ju så illa tvungen när ingen svensk vägledning finns klar. Min rekommendation är verkligen att inte läsa avgörande texter enbart på svenska, i synnerhet gäller det för oss amatörjurister! När du analyserar om er organisation omfattas av NIS2 och när du utformar era åtgärder är det viktigt att vara lite noggrann med dokumentation av vad era avgörande beslut baseras på.

En annan sida av EU-reglering

En intressant artikel av Mazaher Kianpour (från RISE och NTNU) och Shahid Raza (från RISE, MDU och Cybercampus) tittar på hur organisationer reagerar på cybersäkerhetslagar. Det är ju en klassisk insikt att förändrade spelregler inte automatiskt skapar det beteende man egentligen var ute efter... Hotet om sanktionsavgifter och annat kommer naturligtvis alltid vägas mot andra risker och resursbehov.

Följetongen CRA...

Du missade väl inte extrautgåvan av nyhetsbrevet som kom alldeles efter nyår och tittade närmare på den slutgiltiga texten för CRA-förordningen? Ännu så länge är den inte formellt spikad och det finns heller inget datum bestämt när det kan bli aktuellt. Prognosen säger just nu en vecka in i april men det kan mycket väl ändras.

Nu börjar det gå upp för allt fler hur tuffa de närmaste åren kommer bli för många organisationer. Väldigt många är mitt uppe i NIS2-resan (plus DORA och CER för dem som berörs) samtidigt som nu CRA dyker upp på horisonten. CRA ska dessutom sannolikt vara fullt implementerad ungefär samtidigt som den nya Maskinförordningen har sin deadline. Även om det senare inte är förrän 2027 kommer det bli nödvändigt för många organisationer att ta ett samlat helhetsgrepp redan nu på alla dessa kravmassor för att inte behöva göra om jobbet flera gånger.

Jag har försökt förstå vad opensource-världen tänker kring det slutgiltiga förslaget. De tidigare versionerna sågades ju brutalt därifrån men det har blivit nästan märkligt tyst efter det slutgiltiga förslaget. Några tankar har jag hittat, exempelvis från Eclipse Foundantion, OpenForum Europe, Python Software Foundation där tongångarna var mestadels positiva medan Debian var lite mer negativa. Jag hittade också en bra genomgång skriven av Bert Hubert.

För NIS2 gick det att skaffa sig fördelar som leverantör om man var snabbt uppe ur startblocken och visade upp att man kan leverera enligt direktivets krav långt innan de börjar gälla. För NIS2 har det tåget snart lämnat stationen, men för CRA finns fortfarande bra möjligheter att styra upp utvecklingsprocesserna och villkoren för säkerhetssupport på sålda produkter. Säljer du produkter med digitalt innehåll är det viktigt att hugga tag i CRA snabbt! På OT-sidan som ofta har komponenter i drift under lång tid blir det speciellt viktigt att tänka igenom hur lång supportperiod man tänker garantera vid köp!

Jag kan förresten rekommendera en episod av Dataföreningens "Prata CRA lagen med oss", där Olle E Johansson och Per-Erik Eriksson diskuterar den senaste versionen av förordningen:

EUCC är klar!

EUs cybersäkerhetsmyndighet ENISA har annonserat att "EU cybersecurity certification scheme on Common Criteria", (EUCC), är klar. Det är den första av en radda sådana och kommer bland annat följas av en kring molntjänster (EUCS) och en för 5G (EU5G). Det tittas också på möjligheterna på motsvarande upplägg för AI, elektroniska identitetstjänster och för MSSP:er (Leverantörer av managerade tjänster för säkerhet)

Det här är ett spännande och komplext område som kommer få många beröringspunkter med exempelvis CRA-förordningen. Jag får säkert anledning att återkomma till detta!

Jag satsade på rätt häst i labbet!

Om du följt mina äventyr i hemmalabbet vet du att jag snöat in på Proxmox som virtualiseringsmotor. Ett annat vanligt val för virtualisering i hemmalabb är att köra gratisvarianten av VMware ESXi. Nu är jag ännu gladare att jag fastnade för Proxmox när VMware nu annonserat att gratisvarianten av ESXi försvinner. Det har hörts många "vad var det jag sa" från folk som såg detta komma sedan VMware köptes av Broadcom. Det återstår att se om/hur detta slår tillbaka mot VMware men tills dess är min personliga rekommendation att titta på Proxmox.

Har du kollat tändstiften?

Här är en intressant text som egentligen är en presentation som Christofer Dutz höll på "2023 IoTDB Summit" som inte nämner säkerhet en enda gång men som illustrerar en intressant förflyttning i branschen. Nämligen den som går bort från OPC UA och istället rör sig mot MQTT och Sparkplug B. Några av anledningarna till denna trend beskrivs i texten. Det är inte helt klart för mig hur siffrorna ser ut för OPC UA och MQTT men oavsett är det här något som vi OT-säkerhetsmänniskor måste vara uppmärksamma på!

Läsvärt från MSB!

MSB släppte nyligen dokumentet "Cyberangrepp mot samhällsviktiga informationssystem - 25 rekommendationer för stärkt skydd mot cyberangrepp". Det är inte skrivet specifikt för OT-säkerhet men innehåller många relevanta referenser och exempel som borde göra det till ett intressant dokument för de flesta säkerhetsintresserade.

Ska vi höras?

I förra nyhetsbrevet öppnade jag min kalender för alla som vill diskutera något kring OT-säkerhet. Gensvaret blev fantastiskt och jag har haft en radda riktigt roliga samtal, så jag kommer repetera den här texten framöver.

En av de saker jag uppskattar allra mest med mitt jobb är att jag får kontakt med så många intressanta organisationer. Mina uppdrag är typiskt antingen korta alternativ långa och "lågintensiva", vilket öppnar för fler kontakter. Det kan vara som tillfälligt expertstöd i ett projekt, som rådgivare till en IT-chef eller som coach till en säkerhetschef under lång tid, som granskare av kravunderlag eller kanske som "djävulens advokat" när det behövs någon som utmanar lite.

Det är verkligen en förmån att få lite insyn i så vitt skilda verksamheter och att få träffa människor med intressanta utmaningar! Det är märkligt att det kan vara så många likheter mellan OT-säkerhetsutmaningarna i robotceller hos en tillverkande industri, fastighetsautomationen i en extremt känslig byggnad, dricksvattenproduktionen i en liten kommun, en gruvas komplexa värld, de medicintekniska system på det lilla sjukhuset, maskinrummet på riktigt stora fartyg eller någon av alla andra spännande verksamheter som jag kommer kontakt med. I princip 100% av gångerna kan jag dela med mig av något jag lärt mig från en tidigare erfarenhet till nästa kontakt.

Normalt sett sker dessa kontakter som en del av ett uppdrag vilket förstås begränsar vilka människor jag kommer i kontakt med. Jag tänkte att det skulle vara kul att komma i kontakt med fler verksamheter, spännande eller vardagliga, även utan ett aktivt uppdrag, för att se vad vi kan lära av varandra.

Som ett experiment provar jag att öppna kalendern för alla som vill höras för att bolla någon intressant fråga. Vad som helst som har med OT-säkerhet att göra! Du får naturligtvis själv avgöra vad du kan dela med dig av eftersom det formellt sett inte finns några sekretessavtal på plats.

Plocka åt dig en timme här! Vad vill du prata om? Segmentering? NIS2? Samarbete IT & OT? Cool teknik? Ladder Logic kontra Structured Text? Det glamorösa livet på AFRY? Active Directory? Hemmalabbet? Incidentövningar? Du väljer!

Vem är Mats?

Jag är till vardags säkerhetsrådgivare kring OT på AFRY i Västerås. Det här nyhetsbrevet ger jag ut helt privat baserat på mitt intresse för området och utifrån att det verkar matcha ett behov av information kring OT-säkerhet på svenska.

Innan jag blev konsult för några år sedan spenderade jag det mesta av mitt arbetsliv inom kärnkraftsbranschen. Det är härifrån som jag har fått mitt intresse för OT-säkerhet, fysiskt skydd, human performance och säkerhetsskydd.

Jag har ett grundmurat intresse för alla former av säkerhetsfrågor och kanske i synnerhet när det knyter samman kul teknik med utmanande frågor runt hur vi människor hanterar tekniken. På senare år är det nästan uteslutande OT-säkerhet och till viss del säkerhetsskydd som jag arbetat med. Båda två år områden där det är väldigt viktigt att hantera tekniska och mänskliga utmaningar tillsammans.

Jag är alltid väldigt tacksam för alla former av kontakt eller återkoppling från dig som läser detta. Det är intresset från mina läsare som gör det roligt och meningsfullt att hålla liv i nyhetsbrevet. Hör gärna av dig till mats@ot-sakerhet.se !

Det här nyhetsbrevet vänder sig till personer som är intresserade av säkerhet inom OT. Det produceras av Mats Karlsson Landré och får spridas vidare fritt.

Tanken är att det ska innehålla tips om intressanta resurser kombinerat med mina egna tankar om aktuella händelser. Återkoppla gärna med egna idéer eller funderingar till mats@ot-sakerhet.se! Förslag till ämnen eller innehåll tas förstås emot med tacksamhet!

Om du önskar få nyhetsbrevet direkt till din inkorg i fortsättningen kan du gärna kontakta mig på mats@ot-sakerhet.se. Jag lovar att din mejladress inte används till något annat än detta!

Du hittar tidigare nyhetsbrev på ot-säkerhet.se.